Open-source boosters (OSB) are free, short (<4 days) collaborations to maximise the impact of open-source software developed at Imperial.
We offer a collection of set activities that we can carry during the allocated time and that tackle one or another aspect of research software, from deployment to citability. When applying for the OSB (see below), you will need to select only one of these options, but nothing prevents you from applying to different options in subsequent editions of the programme.
To access this programme, the software must be open source already or be made open source as part of the activities carried out during its execution. We also require for the RSE Team to be acknowledged in the software repository and in any immediate publication about the software.
Projects applying to this programme, regardless of them being successful or not, will be included in the Imperial Research Software Directory to increase their findability and impact.
Next application reviews will take place in early August and October.
How to apply
To apply to an OSB call, you will need to complete a short application form to justify the need for the collaboration and why it cannot be sorted out via other means (eg. Code surgeries, standard software projects, third-party schemes).
There is a rolling call open with application reviews every 2 months. The team will strive to review the applications, announce the winners and provide feedback within 2 weeks of the review date. After that, the team will work with you to arrange an appropriate timing to work on the project that, once allocated, will be completed within 1 month.
The following diagram offers a better idea of the timeline for the OSB programme:
Image description: an image depicting the timeline for the OSB programme. Application phase, 2 weeks - OSB call opens. Review phase, two weeks - RSE team review applications - winners announced and feedback provided. Allocation phase, days -project starts. Execution, <4 days over 1 month - project ends.
We aim to review the applications every 2 months, but this might suffer from minor changes due to summer or Christmas holidays, for example. Typically, there will be 1 accepted project per review cycle. More information for each call will be provided via the Imperial RS Slack Workspace, and the Imperial RS Community Newsletter.
Options for the OSB programme
The following list shows the range of activities that the Research Software Engineering (RSE) Team can do for your software within this programme.
You will need to select just one of them during the application process.
You can discuss with RSE beforehand which option is most appropriate for your software and goals via a Code Surgery or via Slack (best effort basis).
In all cases, appropriate training and knowledge transfer to the researchers is included, so they can take over the maintenance and further development of the project themselves once the collaboration is completed.
Some of the options scale with the complexity of the software and therefore the OSB programme might not be enough to complete the tasks in the time available. This is one of the selection criteria considered when selecting the projects (see below).
Options available
- Option 1: Paper pre-submission assessment
- Option 2: Software deployment
- Option 3: Documentation infrastructure
- Option 4: Audit of software quality and performance
This option is designed to support the publication of research papers that present results obtained with the software, validating those results, facilitating citing the software in the paper and using it by potential reviewers or readers. It involves:
- Assess the software-related claims made in a research paper
- Check the reproducibility of the results presented (produced by the software)
- Ensure installation and usage instructions are correct and clear. Some minor updates of the installation procedure might be done here if deemed necessary, but the purpose of this task is not to refactor the installation process. See the “Software deployment” task for that.
- Archive the software with a DOI (with Zenodo). Note that the repository will be made open source at this stage if not open already, using a BSD-3 license unless agreed otherwise. See the section about Legal Information.
- Add instructions about how to cite the software correctly
This option focusses on ensuring the software is easy to deploy in the appropriate platform, typically other researchers’ computers. This deployment process might range from straight forward to really complicated depending on the nature and number of dependencies of the software. For the most complex cases, a standard Software Project might be required.
The specific activities to de done depend on the programming language(s) of the software:
- Setup a versioning system.
- Setup an automated building and deployment system, normally via GitHub Actions or similar.
- Deploy package to PyPI (Python only) in source and wheel form (when possible).
- Deploy package to conda-forge (Python, C++ and Fortran[AD1] ).
- Ensure installation instructions are correct and clear.
This option puts in place the infrastructure to build and deploy the documentation for the software using Read the Docs or GitHub Pages, to be agreed at the start of the project.
Underlying documentation tools that could be setup, depending on the programming language and complexity, include:
- Sphinx
- Pdoc
- MKDocs
- Doxygen
Most of this task focuses on training the researchers on how to populate the documentation with the relevant information.
This option will review the software repository as a whole, providing detailed feedback for the developers to action on aspects like:
- End user documentation
- Technical documentation
- Code style and standards
- Use of appropriate tooling and design patterns
- Profiling and performance assessment (depending on the software complexity and time permitting)
A report will be produced and/or issues in the software repository open to guide the developers in the implementation of the key aspects identified during the audit.
Selection criteria
The following aspects of the software will be evaluated by the members of the RSE Team to select the awarded projects on each round. Aggregated feedback will be provided for each selection criteria as well as recommendations for future steps.
- The RSE Team has the appropriate expertise to tackle the project
- The task is doable in the time available
- The OSB programme is the best route to improve this software
- The value and impact of the software is well justified
- The software has not benefited yet from the OSB programme